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REPORT  SUMMARY 

The  Advisory  Committee  Meeting  was  held  at  Burroughs  (Paoli, 
Pennsylvania),  Octoher  30-31^  1969*   The  purpose  of  the  meeting  was  to 
review  the  status  of  the  Hardware  "being  constructed  at  Burroughs,  and 
to  review  the  work  being  done  on  Software  at  the  University  of  Illinois. 
Burroughs  demonstrated  the  PE  and  other  subsystems.   It  was  tentatively 
agreed  that  a  future  meeting  be  planned  to  give  a  close  scrutiny  to 
programming  languages  being  developed  (e.g.,  TRANQUIL,  GLYPNIR,  FORTRAN). 

The  semi-conductor  memories  to  be  produced  by  Fairchild  for 
Burroughs  are  still  behind  the  production  schedule,  due  to  yield 
problems  with  the  memory  chips.   The  first  memory  delivery  to  Burroughs 
is  expected  March  16,  1970  (a  slippage  of  two  months);  the  last  (70th) 
memory  is  scheduled  for  delivery  on  June  5^  1970  (a  slippage  of  one 
month) . 

The  prototype  processing  element  has  been  built- -Burroughs 
has  begun  production  of  the  PE--and  most  instructions  have  been 
"debugged. "  A  minor  "slow  down"  is  expected  in  the  twenty  megahertz 
clock  as  a  result  of  testing  being  performed  on  the  prototype  PE. 

Software  and  hardware  for  the  PEX  Control  Computer  (PDP-9) 
have  been  completed;  the  computer  will  be  shipped  to  Burroughs  in 
January.   The  first  of  the  University's  production  diagnostics  for 
printed  circuit  cards  and  the  processing  element  have  been  delivered 
to  Burroughs . 

Burroughs  has  submitted  fixed  price  proposals  for  ILLIAC  IV 
documentation,  power  supplies,  and  PE's.   These  proposals  are  currently 
being  evaluated. 

In  December,  a  Project  Business  Office  (PBO)  was  established 
for  the  ILLIAC  IV  Project.   This  office  will  deal  with  internal 
administration--budgets,  building  requirements- -and  will  interface  with 
the  University  Administration. 
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Bids  for  the  construction  of  the  Center  for  Advanced  Computa- 
tion building  vere  received  and  approved  by  the  University  of  Illinois 
Board  of  Trustees;  a  contractor  has  been  selected,  and  construction  of 
the  building  has  started. 
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1.   HAEDWARE 


1.1  Logic  Simulation  and  Diagnostics 
1.1.1  Logic  Simulation 

1.1.1.1  EE  Simulator 

The  net  lists  (wire  lists )^  generated  during  the  previous 
quarter  for  the  37  Processing  Element  (EE)  card  types ^  have  been 
maintained  and  updated  during  this  period.   In  addition,  net  lists  for 
the  5  Memory  Logic  Unit  (MLU)  card  types  were  compiled  from  Burroughs 
logic  diagrams;  errors  in  translation  and  in  card  punching  of  the  net 
lists  were  removed  completely.   All  of  the  MLU  card  net  lists  have  "been 
released  for  simulation  and  test  generation. 

1.1.1.2  CU  Simulator  System 

The  Control  Unit  (CU)  Card  Logic  Simulator  System  of  programs 
(except  the  simulator  Body  Generator  and  Merge  programs)  have  been 
modified,  wherever  necessary,  to  satisfy  the  requirements  of  the  CU- 
Section  System. 

The  modified  Update  program  will  delete  or  insert  records 
into  the  backplane  wire  list  and  will  rearrange  the  records  into  the 
form  required  by  the  WEDTRl  program. 

The  new  WEDTRl  program  will  detect  missing  wires  and  produce 
an  error  list  on  disk  which  can  then  be  used  as  input  to  the  Update 
program.   It  is  not  possible  to  exactly  update  the  wire  list  in  this 
program;  however,  the  program  does  provide  a  way  to  add  many  of  the 
interface  signals.   Otherwise,  this  program  is  similar  to  the  earlier 
WEDTRL  program,  except  that  the  disk  spaces  are  larger--to  accommodate 
the  larger  files. 

The  WEDTR2  program  now  accepts  a  file  which  is  the  result  of 
partitioning  a  CU  card  into  three  parts:   Input,  Output,  and  Combina- 
tional parts.   Partitioning  is  effected  to  increase  the  efficiency  of 
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simulation  for  such  situations  as  the  occixrrence  of  looped  storage 
elements.   During  the  pin  sorting  hlock,  each  pin  is  examined  to  see 
whether  it  "belongs  to  Input,  Output,  Comhinational  or  to  any  combina- 
tion of  the  three  partitions  of  the  card.   Due  to  the  partitioning, 
some  logic  elements  -will  he  duplicated  in  the  cards--this  information 
is  added  to  the  file  while  processing  it.   ■WEDTR2  produces  an  arc  list 
which  takes  into  account  the  partitioning,  and  sorts  the  records  "by  the 
package  location  and  pin  number. 

The  only  modification  in  the  Leveler,  Reduce  and  Housekeep 
programs  is  the  enlarging  of  the  disk  spaces  to  handle  larger  files. 

1.1.2  Card  Test  Generation 

1.1.2.1  Card  Test  Generator  System 

The  Card  Test  Generator  System  was  used  during  this  period 
to  obtain  test  patterns  for  some  EE  and  CU  cards. 

Due  to  the  higher  complexity  of  the  CU  cards,  slight  modifica- 
tions of  the  basic  system--such  as  the  ability  to  use  manually  generated 
input  patterns  with  the  aid  of  TESLA,  merged  with  inputs  generated  by 
the  Pattern  Generator  program  as  inputs  to  the  simulator- -have  been 
implemented. 

The  necessity  of  generating  additional  information  to  be  used 
by  the  Test  Translation  program  for  fault  location  purpose  required  the 
addition  of  a  new  program  to  the  system.   An  initial  version  of  this 
program  is  operational  and  a  new  version  of  the  program  with  increased 
capability  is  under  development. 

1.1.2.2  Card  Test  Translation 

Work  in  this  field  was  concentrated  in  three  principal  areas: 
production  of  test  dictionaries  (including  input  and  output  patterns); 
automatic  translation  of  test  patterns  into  PEXTAP  programs  suitable 
for  use  with  the  CU  Card  Tester  Adapter  for  the  PEX;  aad  automatic 
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translation  of  test  patterns  into  programs  which  can  be  run  on  the  Texas 
Instruments  561  Logic  Tester  which  will  he  used  to  test  PE  cards. 

Test  patterns  produced  by  the  Test  Generator  System  are 
converted  into  test  dictionaries  which  are  used  for  manual  switch 
tester  debugging  of  cards  and  to  provide  detailed  information  when 
failures  are  detected  by  any  of  the  automatic  procedures. 

For  each  output  pin  of  a  board,  failure  modes,  (and  any 
indistinguishable  equivalent  failures)  which  can  cause  an  anomalous 
output,  are  listed.   In  addition,  cross  references  between  failure 
modes  and  test  patterns  are  supplied  to  simplify  the  task  of  fault 
location.   Although  the  test  dictionary  production  program  previously 
existed  in  a  primitive  form,  extensive  revisions  have  been  made  to 
provide  additional  information  to  the  user  and  to  format  the  information 
in  the  most  useful  manner. 

A  working  version  of  the  PEXTAP  translation  program  has  been 
completed,  and  EEXTAP  code  generated  by  it  has  been  sent  to  Burroughs 
for  evaluation.  Further  improvements  will  be  made  during  the  next 
quarter. 

Programs  have  been  written  which  automatically  generate  valid 
programs  for  the  TI-56IA  Automatic  Printed  Circuit  Card  Tester.   These 
programs  will  be  used  to  generate  programs  for  testing  various  PE  boards. 
They  are  generated  from  the  wire  list  of  each  board  and  the  failure  test 
patterns  applied  to  each  input  pin  with  the  associated  expected  good 
output.   The  programs  have  been  written  within  the  constraints  imposed 
by  Burroughs  on  the  assignment  of  input  pins  to  the  Texas  Instruments 
561  Logic  Tester.   The  boards  for  which  satisfactory  test  generation  can 
be  performed  are  static  (i.e.,  no  latches)  logic  boards  with  27  input 
pins  or  less.   A  modified  program  will  be  written  to  generate  the  test 
program  for  those  boards  with  more  than  27  input  pins.   Special  routines 
for  setting  and  resetting  latches,  which,  thus  far,  have  not  been  written, 
are  necessary  for  testing  this  type  of  board.   In  addition,  possible 
problems  exist  if  non-standard  voltage  level  assignments  are  required  on 
special  boards. 
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1.1.2.3  Generation  and  Evaluation  of  Card  Tests 

All  of  the  PE  card  tests  generated  by  the  Card  Test  Generator 
System  have  "been  released  to  Burroughs  for  production  testing  of  EE 
cards.   These  tests,  however,  will  he  revised  in  accordance  with  card 
design  modifications  and  improvements  in  the  Test  Generator  System. 

MLU  Card  Tests  are  being  generated  for  production  testing. 

Significant  improvements  in  the  Test  Generator  System  give 
higher  resolution  in  locating  failed  components  with  test  dictionaries. 
An  example  of  the  new  test  dictionary  has  been  sent  to  Burroughs. 

All  of  the  revised  EE  card  tests  including  the  MLU  card  tests 
are  ready  to  be  generated  whenever  design  modification  infonaation  is 
available  from  Burroughs. 

A  correlation  of  failure  modes  in  DIL's  from  a  circuit  analysis 
by  Burroughs  to  a  logical  analysis  by  the  Diagnostics  group  was  completed 
for  ten  of  the  metal  patterns.   This  correlates  actual  circuit  failure 
modes  with  the  failure  modes  assumed  in  the  Card  Test  Generator.   One 
class  of  circuit  failures  was  found  which  is  not  presently  covered  in 
the  Card  Test  Generator.   It  will  be  covered  when  analysis  of  all  DIL 
types  is  completed. 

1.1.3  EE  Diagnostics 

1.1.3.1  Path  Test 

The  Detection  Phase  Path  Tests  for  the  prototype  PE  have  been 
released  to  Burroughs  after  some  errors  in  expected  responses  were 
removed.   A  few  errors  and  failures  in  the  prototype  EE  and  the  EE 
exerciser  were  found;  some  of  them  were  located  with  the  Detection  Ehase 
Fath  Test.   The  Detection  Ehase  Path  Test  is  also  valid  for  production 
EE  testing. 

Since  a  masking  function  is  required,  the  Location  Ehase  Eath 
Test  should  be  executed  with  the  EEX  under  computer  control.   (This 
masking  function  cannot  be  provided  by  the  EEX- -it  must  be  performed  by 
the  PDF- 9. ) 
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The  test  dictionary  of  the  Location  Phase  Path  Tests  will  be 
useful  to  locate  failures  with  the  Detection  Phase  Path  Tests  until  the 
PE  exerciser  is  hooked  up  to  the  PDP-9  and  the  control  program  system 
in  the  PDP-9  supervises  the  Location  Phase  Path  Test  by  its  masking 
function. 

1.1. 3*2  Combinational  Test 

Re-evaluation  of  the  combinational  tests  was  started  again  in 
this  period.   Several  functional  tests  will  be  released;,  one-by-one, 
after  verification  with  the  PE  simulator. 

1.1. 3*3  Control  Logic  Tests 

The  main  task  in  this  quarter  was  to  find  a  good  algorithm  to 
check  sneak  paths  in  the  graphs  corresponding  to  Boolean  equations  of 
PE  control  logic . 

An  algorithm  with  parallel  checking  capacity  is  used  for  the 
test  generation  (EQUATN/TESTGEN) • 

In  order  to  take  advantage  of  the  parallel  checking,  two 
programs  (EQUATN/R]roRAM2  and  EQUATN/REVPTHI)  were  written  prior  to 
EQUATN/TESTGEN.   These  two  programs  change  the  formats  of  PCM  output 
files,  and  some  others,  in  order  to  fit  the  required  formats  of  input 
files  of  EQUATN/TESTGEN. 

The  program  EQUATN/TESTGEN  has  been  written  and  is  being 
debugged.   This  program  will  give  the  test  patterns  for  the  PE  control 
logic.   The  number  of  tests  is  approximately  ^50.   This  set  of  tests 
is  good,  not  only  for  detecting,  but  also  for  locating  the  failures  in 
the  PE  control  logic. 

1.1.3.^  Functional  Tests 

In  this  quarter,  functional  tests  were  run  on  23  test  routines 
and  the  results  were  sent  to  Burroughs.   In  several  cases,  the  PEXTAP 
source  code  was  changed  to  eliminate  discrepancies  between  actual  and 
expected  responses  in  the  simulator  portion  of  the  tests. 
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The  ACT  program  required  modification  to  make  it  more  general 
and  to  improve  its  execution  efficiency.   It  now  translates  from 
assembled  EEXTAP  code  to  simulator  input  code  and  rearranges  the  input 
for  parallel  simulation  at  an  average  of  2'JO   cards  per  minute. 

1.1.4  PEX  Computer  and  Supervisor  System 

Both  the  hardware  and  software  systems  necessary  for  interfacing 
the  H)P-9  computer  to  the  FEX  were  completed  during  this  quarter. 

The  necessary  components  for  the  EEX  interface  arrived  at  the 
beginning  of  the  quarter  and  interface  construction  was  accomplished 
with  a  minimum  of  difficulty.   The  interface  was  completed  at  the  same 
time  as  the  PEX  supervisor  software.   To  permit  the  latter  to  be  checked 
out,  additional  logic  was  temporarily  added  to  the  interface  to  simulate 
the  reactions  of  the  actual  FEK,      The  interface  and  the  software  were 
then  debugged  as  completely  as  possible  without  actually  being  connected 
to  the  EEX. 

The  minor  modifications  which  must  be  made  to  the  PEX  are 
currently  being  done  by  Burroughs.   It  is  anticipated  that  the  EDP-9  will 
be  shipped  to  Paoli  at  the  beginning  of  the  next  quarter. 

The  EDP-9  has  proven  useful  in  other  ways.  Utility  routines 
have  been  written  which  produce  paper  tapes  for  both  the  PEIX  and  the 
TI-561  from  B5500-generated  magnetic  tapes.   This  eliminates  the  need 
for  extra-project  computer  services  which  were  previously  necessary  for 
such  conversions. 

1.2  Design  Automation 

Within  the  past  quarter,  the  layout  of  CU-boards  was  completed. 
Forty-five  computerized  layouts  were  completed  at  the  University  for 
Burroughs  Corporation.  With  the  completion  of  the  CU-artwork,  all  of  the 
detailed  PC  layout  for  ILLIAC  IV  is  now  complete. 
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2.   SOFTWARE 


2.1  Operating  Systems 

2.1.1  Operating  System  I 

The  operating  system  is  in  the  last  stages  of  coding  and 
delDugging  that  can  be  performed  on  the  B5500.   The  design  is  completely 
frozen.   After  final  debugging  on  the  B6500,  the  effort  will  turn 
to  1)  remedying  deficiencies  in  the  design  and  2)  accommodating  the 
input/output  provisions  incorporated  in  TRAMQUIL,  GLYPNIR  and  ASK. 

2.1.2  Operating  System  II 

2.1.2.1  Introduction  to  Operating  System  II 

The  primary  motivation  for  the  SYSTEM  II  approach  is  to 
achieve  maximum  use  of  the  ILLIAC  IV  array.  Fundamental  is  that  the 
control  portion  of  the  complete  algorithm  he  explicitly  placed  on  the 
B65OO  which^  as  the  hardware  is  designed,  is  the  controller  for  even 
such  intimate  actions  as  transmissions  between  ILLIAC  disk  and  PE 
memory.   The  foundations  of  the  approach  are  the  ILLIAC  KEEICEL  statement 
and  ILLIAC  resource  allocation  declarations  which  will  be  added  to  a 
standard  B65OO  compiler  (e.g.,  FORTRAN),  and  extensions  to  the  B65OO 
Operating  System  (MCP)  which  are  designed  to  include  ILLIAC  IV  as  a 
resource  of  the  composite  system. 

The  applications  programmer  merely  embeds  (non- nested)  ILLIAC 
computations  in  his  "control  program"  which  is  thereby  tailored  to 
control  the  set  of  ILLIAC  computations  which  are  embedded  in  it.   Thus, 
such  actions  as  program  segment  overlay  and  core-disk  data  transmissions 
are  specified  in  a  natural  way  by  the  applications  prograimner  without 
his  thinking  about  this  facet  of  his  program's  interaction  with  the 
system.  Multiprogramming  between  such  programs,  and  multitasking  within 
them  is  fully  supported  by  the  Burroughs  MCP.   Finally,  an  incremental 
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approach  to  ILLIAC  IV  is  provided  ty  the  language  which  is  central  to 
the  SYSTEM  II  approach  since  the  B650O  compiler's  language  is  a  proper 
suhset  of  that  language. 

Implementation  of  the  MCP  extensions  has  begun  "by  -writing  them 
in  SIMULA- -a  simulation  language  which  parallels  the  facilities  of  ESPOL 
(the  language  in  which  the  MCP  is  written)  very  closely. 

2.1.2.2  The  KERIIEL  Statement 

The  canonical  KERNEL  statement  is  a  quadruple  whose  ordered 
four  parts  are : 

1)  EE  memory  declarations  local  to  the  KERNEL  block; 

2)  Input  transmissions  from  ILLIAC  disk  to  PE  memory 
all  of  which  must  be  recognized  as  complete  by  the 
B65OO  before  the  next  step  can  proceed; 

3)  The  ILLIAC  computational  algorithm; 

h)     Output  transmissions  from  PE  memory  to  ILLIAC  disk, 
which  must  be  complete  before  KERNEL  completion 
notification  is  given  to  the  B65OO  control  program. 

All  of  the  information  necessary  to  execute  a  given  KERNEL  must  be 
available  in  the  B65OO  at  run  time  when  control  reaches  the  KERNEL;  thus, 
input  and  output  record  indices  and  ILLIAC  memory  size  requirements  can 
depend  on  variables  whose  values  are  available  in  the  B65OO  at  the  time 
KERNEL  execution  is  called  for.   However,  no  parameters  for  a  given 
instance  of  a  KERNEL  can  depend  on  values  detennined  by  the  execution  of 
that  instance  of  that  KERKEL. 

Any  combination  of  the  constituents  of  a  KERNEL  may  be  elided; 
not  all  of  the  allowed  combinations  are  logically  desirable,  however. 

Three  forms  of  KERNEL  executions  are  possible.   They  are 

1)  ILLIAC  <KERNEL  quadruple >;  the  B650O  waits  until 
KERNEL  completion  before  proceeding. 

2)  ILLIAC  PROCESS  ^CERMEL  quadruple >;  the  B65OO 
proceeds  immediately  to  the  next  statement; 
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simultaneous  processing  occurs  on  the  ILLIAC  array 
and  the  B650O. 

3)   ILLIAC  ON  <event  designator>  <KERIIEL  quadruple>; 
KERNEL  completion  causes  the  specified  EVENT; 
simultaneous  processing  occurs  on  the  ILLIAC  array 
and  the  B65OO. 


2.2  Translator  Writing  System 

During  this  quarter,  ISL/DISK  was  added  to  the  system,  com- 
pleting the  system  as  outlined  previously.   Thus,  a  user  may  write  the 
syntax  of  his  language  in  TWINKLE,  write  the  semantics  in  ISL,  and 
generate  a  compiler- -simply  by  giving  everything  to  TWINKIE/DISK--the 
other  necessary  programs  will  be  run  in  order  automatically.   Also,  it 
is  possible  to  run  each  step  independently,  if  that  should  be  desirable. 

The  documents  describing  ISL,  the  Translator  Writing  System, 
and  TWINKLE  have  been  produced. 

An  effort  was  begun  to  overhaul  the  parser  files  to  make  them 
as  small  and  as  efficient  as  possible.   A  patch  to  the  ALGOL  compiler 
to  allow  conditional  voiding  of  cards  was  added.   Also,  some  new  action 
calls  (parameterized,  setting  and  testing  a  bit,  incrementing  or 
decrementing  and  testing  a  counter)  will  be  added  which  will  allow 
certain  features  to  be  done  more  q_uickly  than  would  otherwise  be 
possible. 

A  persistent  problem  with  one  of  the  Floyd  production  groups 
has  been  solved  and  the  necessary  changes  to  implement  the  solution  will 
be  made  along  with  the  above  changes  during  the  next  quarter. 

2. 3  Compilers  and  Translators 

2.3.1  TRANQUIL 

The  TRANQUIL  group  participated  in  a  benchmark  effort  which 
clearly  showed  that  the  current  compiler  would  produce  code  which  would 
not  execute  sufficiently  efficient  to  attract  users.   In  the  interest 
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of  improving  these  figures,  the  TRANQUIL  group  has  engaged  in  a 
substantial  project  of  evaluation. 

At  the  same  time,  efforts  to  debug  the  current  compiler  were 
continued,  primarily  in  those  areas  not  directly  affected  by  the 
evaluation.   The  areas  of  set  definition  and  operations,  procedure 
calls,  and  sequential  loop  control  have  now  been  successfully  simulated. 
The  TRAIilQUIL  group  has  also  been  preparing  for  another  reduction  in 
personnel  and  general  reallocation  of  resources. 

A  document  entitled  "A  TRANQUIL  Programming  Primer"  [1]  has 
been  produced.   It  will  be  available  for  distribution  early  in  1970 • 
It  includes  a  good  description  of  the  TRANQUIL  language  and  its  use, 
comparisons  with  FORTRAN  and  ALGOL,  and  exercises  and  answers  against 
which  the  reader  may  test  his  skill. 

2.3.2  GLYPNIR 

A  review  of  the  status  of  GLYPNIR  was  made  diaring  the  last 
quarter  of  1969-   The  leadership  of  the  project  was  transferred  from 
Duncan  Lawrie  to  James  L.  Parker.   It  was  determined  that  GLYPNIR 
should  be  given  a  larger  exposure  to  users  and  that  classes  in  GLYPNIR 
programming  would  be  held. 

The  mathematical  subroutine  library  was  almost  completed.   A 
FOR  statement  which  utilized  the  machine  fast  loop  and  index  instruction 
was  added.   Code  has  been  inserted  to  accept  the  "VECTOR"  declaration. 
Writing  of  a  user's  manual  to  complement  the  education  program  was  begun. 

Further  projects  for  expanding  the  language  are: 

Extended  indexing 
Extended  routing 
CU  index  variable 
Define  macro  facility 
32-bit  arithmetic 
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2.i|  Assembler 

Work  was  begun  on  the  macro  assembler  in  September.   By 
mid-November,  a  first  version  vas  running  on  the  B5500.   At  this  time, 
work  on  the  assembler  was  suspended  for  the  remainder  of  the  quarter 
in  order  to  investigate  the  feasibility  of  the  next  version  of  the 
Operating  System  (System  II). 

2.5  B^^OQ  Operation 


No.  of 

Process 

Jobs 

Hours 

October 

10,151 

287 . 94 

November 

9.603 

252.18 

December 

9,697 

93-38 

The  present  status  of  the  MOP  is  Mark  X,  LEVEL  00. I9.  Machine 
use  has  been  moderate  to  heavy,  with  an  average  of  approximately  330 
jobs  being  run  per  day  (throughput  has  been  very  good). 

Design  Automation  finished  their  work  and  gave  up  their  use  of 
the  machine  on  November  24,  I969. 

Batch  Processing  is  now  being  offered  as  a  service  to  all 
users.   A  Cold  Start  procedure  has  been  initiated  in  which  user's  files 
are  no  longer  dumped. 
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3.   APELICATIONS 


3.1  Numerical  Analysis 

3.1.1  Monte  Carlo  Transport 

Work  on  Radiation  Transport  phenomena,  using  a  Monte  Carlo 
method,  is  heing  continued.   The  geometry  heing  considered  is  two- 
dimensional  (cylindrical  synmietry)  with  domains  consisting  of  32  x  6k 
cells.   Density  is  a  fimction  of  space,  while  the  absorption  and 
scattering  coefficients  are  functions  of  temperature.   The  process  is 
nonlinear  in  the  sense  that  the  number  of  photons  to  be  emitted  in  each 
cell  is  dependent  upon  the  temperature,  which  is  in  turn  re-evaluated 
after  each  time  step  according  to  the  energy  transferred  to  each  cell. 

The  process  has  been  coded  into  a  number  of  subroutines 
(about  twenty),  some  of  which  will  be  combined  after  debugging.   The 
programs  have  been  written  in  GLYENIR  and  have  been  partially  debugged 
using  the  simulator. 

3.1.2  Eigenvalues 

3.1.2.1  Matrix  Storage  Methods 

3.1.2.1.1  Matrix  Storage  for  Jacobi's  Method 

The  modified  Jacobi  method  for  eigenvalues  of  symmetric 
matrices  has  been  revised. 

(1)  A  new  "triangular- skew"  storage  scheme  has  been  developed 
[2]  which  makes  possible  a  more  efficient  moving  of  elements  in  core. 
The  mapping  of  the  elements  a. .  into  PE-memory  is  done  as  follows: 

for  0<i<-|--l,      j>i 


a.  .  -*  loc   i 


,    FE Ui    (j(mod  /n))    +     T"     ^-  iO    +  l)      (mod  n) 


-Ik- 


and  for  p  <  i  <  n  -  1 


ij 


loc  j 


i  -  f  +  1.  EE  L/^  (i(mod  /n)  +  l)  -h 
MJ  -  |)  (s^  ^  1)  +  ij  (Tiiod  n) 


1  -  (n/2) 


n  is  the  size  of  the  matrix  such  that  Jh.    is  an  even  integer  and  I  xj  is 
the  greatest  integer  <  x.   Any  n  not  satisfying  this  relationship  is 
adjusted  in  a  manner  fully  described  in  [2]. 

(2)  The  classical  and  modified  Jacobi  methods  are  described 
in  "Eigen-Value  Problems"  [3].   In  that  doc-ument  a  shuffle  of  the  first 
row  and  first  column  was  suggested  in  order  to  subject  all  off-diagonal 
elements  to  the  elimination  process. 

A   major  time-saving  factor  has  been  found  by  not  subjecting 
the  matrix  to  the  above  mentioned  type  of  orthogonal  transformation  but 
rather  to  the  orthogonal  transformation 


HAH 


with  H  = 


0 


-1 


Ig  0 


,  H  H  =  I 


where  I  is  an  (n  -  m)  x  (n  -  m)  and  Ip  is  an  (m  x  m)  identity  matrix. 
The  factor  m  is  determined  by 


max 


^  |a,J  (i  ^   j) 


ij 


i.e.^  m  is  the  row  index,  i,  which  contains  the  maximal  value  of  the 

svia   of  the  absolute  values  of  the  elements  in  this  row.   (See  flow  chart, 

part  B. ) 

(3)   It  may  be  noted  that  Jacobi 's  method  can  be  applied  to 
the  set  of  all  symmetric  matrices  by  subjecting  the  matrix  A  to  the 
test  of  diagonal  dominance  according  to  the  criterion 


a.  .   >  E   la.. 

11    •  •   ij 

i^J    "' 


(i  ^  j) 
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ROWSUMl    (A,PAX,N) 
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no 
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If  a  matrix,  A,  does  not  satisfy  this  criterion  then  a  factor,  "b,  is 
determined  as  follows : 

h  =  max  (la..!  fZla..!)     (ir^j)^ 

i.e.,  we  form  a  diagonally  dominant  matrix  B  =  A  +  hi  (see  flow  chart, 
part  A),  then 

A  =  WAW"^  =  W(B  -  hl)W^  =  WBW"*^  -  hi  =  A'  -  hi 


where  A  =  diag  {X.    (A)).   Besides  a  20  percent  saving  in  time,  a  gain 

in  the  accuracy  of  the  eigenvalues  and  the  eigenvectors  has  heen 
achieved. 


3.1.2.1.2  Matrix  Storage  for  QR-Algorithm 

The  QR  method,  developed  hy  J.  Francis  [h],   consists  of  two 
steps:   (1)  reduction  of  a  given,  real  matrix  to  almost  triangular  form, 
and  (2)  application  of  QR  transformation  on  this  matrix.   A  program  for 
this  method  was  written  for  the  B5500  to  acquire  a  thorough  understanding 
of  the  prohlems  involved. 

The  elementary  elimination  method  and  Householder ' s  method 
were  tested  for  the  first  step.   Though  Householder's  method,  which 
uses  unitary  transformation,  is  stahle  as  far  as  rounding  off  error 
accumulation  is  concerned,  the  elementary  elimination  method  requires 
only  half  the  number  of  multiplications  that  Householder's  method 
requires.   The  elementary  elimination  requires  5/6  n-^  multiplications 
in  contrast  to  5/3  n-^  multiplications  for  Householder's  method.   The 
result  of  the  test  indicates  no  significant  differences  hetween  the  two 
methods  for  well  conditioned  prohlems --both  in  accuracy  of  eigenvalues 
and  in  the  numbers  of  iterations  required  in  finding  the  eigenvalues 
from  the  resulting  triangular  matrices. 

Since  the  QR  method,  as  it  is  now,  is  not  suitable  for 
parallel  processing,  the  modified  QR  method  (QPR,  October,  November, 
and  December,  I968  [5])  is  being  considered.   This  method  requires 
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ll/6  n3  multiplications  for  one  iteration,  which  corresponds  to  n/2 

p 
iterations  in  the  ordinary  QR  method,  compared  with  5  n  for  the 

classical  method. 

A  study  of  the  rate  of  convergence  and  the  roundoff  errors  of 
the  modified  QR  method  is  under  way. 


3.1.3  Pattern  Matching  Problem 

Daring  this  quarter,  a  research  effort  was  begun  into  the 
area  of  pattern  matching.   The  problem  is  to  check  a  source  string,  e.g., 
an  English  sentence,  and  locate  a  given  matching  pattern--a  word.   Such 
codes  have  been  written  on  serial  machines,  and  an  attempt  has  been 
made  to  find  a  process  to  make  effective  use  of  the  parallelism  in 
ILLIAC  IV.   The  method  chosen  will  be  referred  to  as  the  Two  Phase 
Method.  A   program  has  been  coded  using  ILLIAC  TV  assembler  language, 
ask/ ASK  II  C;  rough  timing  estimates  have  been  obtained  (about  80  times 
faster  than  the  Burroughs  85OO).   A  final  stage  of  simulation  has  been 
reached  using  the  ILLIAC  TV  simulator,  SSK/SSK.  More  details  will 
appear  in  an  ILLIAC  TV  document. 

3.2  Linear  Programming 

A  significant  portion  of  this  quarter  has  been  devoted  to 
consideration  of  possible  input  and  output  processors  for  the  linear 
programming  system.   Linear  problems  of  ILLIAC  IV  dimensions  require  a 
sizeable  amount  of  input  data;  the  system  should  contain  features  which 
facilitate  the  specification  (input)  of  these  large  models  by  the  user. 
In  addition,  the  conversion,  pre-  and  post-processing  of  these  data 
(outside  the  solution  routines),  consumes  a  substantial  amount  of  the 
computer  run  time  for  the  problem.   Thus,  the  input  and  preprocessing 
facilities  are  an  important  part  of  a  large  linear  programming  system. 
The  LPS  preprocessor  design  effort  will  continue  to  interact  with  the 
development  of  sophisticated,  flexible  (user)  input  systems. 

The  investigation  of  the  Gradient  Projection  method  as  a 
suitable  optimization  technique  for  large  linear  and  nonlinear  problems 
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"Was  concluded  this  quarter.   Results  appear  in  "A  Nonlinear  Progranmiing 
Algorithm  for  an  Array  Computer"  [6],    and  in  "Gradient  Projection  Method 
for  Linear  Programming"  [7]- 

3. 3  Long  Codes 

In  order  to  evaluate  the  algorithms  developed  for  the  identi- 
fication of  dynamic  systems,  a  set  of  programs  -will  "be  developed  to 
model  a  dynamic  system  and  produce  a  stream  of  observation  vectors  to 
he  manipulated  "by  the  various  identification  programs  to  be  tested. 

At  each  time  step,  a  new  system  state  vector  is  produced  using 
the  previous  state  vector  and  a  predetermined  transition  matrix.   Time- 
varying  systems  may  he  modeled  hy  using  a  different  transition  matrix 
at  each  time  step.   Initial  studies  -will  concentrate  on  constant- 
parameter  systems,  where  an  invariant  transition  matrix  is  used.   Noise 
vectors  may  he  added  directly  to  the  system  state  vectors  or  to  the 
observation  vectors,  which  are  obtained  by  pre -multiplying  the  state 
vectors  by  a  predetermined  observation  matrix  (or  matrices  if  a  time- 
varying  system  is  to  be  modeled). 

A  separate  noise  generator  program  produces  vectors  whose 
elements  are  random  variables  having  a  Gaussian  distribution  with  any 
specified  covariance. 

The  noise  generator  program  now  has  the  capability  to  produce 
noise  vectors  having  a  covariance  matrix  equal  to  a  scalar  multiplied  by 
an  identity  matrix.   Also,  the  routines  to  produce  the  state  vectors 
and  observation  vectors  are  essentially  complete. 

After  the  noise  generator  program  is  extended  to  allow  more 
general  covariance  matrix  specifications,  and  when  routines,  such  as 
matrix  inversion- -that  are  used  by  most  identification  algorithms --are 
coded,  various  identification  processes  will  be  programmed  and  evaluated 
against  published  results. 
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3-h     Radar  Data  Processing 

The  Fast  Fourier  Transform  (FFT)  subroutines  to  handle  data 
points  (ranging  from  8  to  ^1096)  have  "been  coded.   Several  parts  of  the 
subroutines  have  been  completely  debugged;  however,  debugging  has  been 
slow  due  to  the  inaccessibility  of  the  B5500  computer  and  to  the 
requirements  of  personnel  working  on  higher  priority  tasks.   Several 
new  improvements  have  been  investigated  and  are  being  incorporated  into 
the  present  programs.   Another  routine  for  handling  different  data 
structures  is  being  investigated  and  may  be  programmed  as  part  of  the 
routines. 

Effort  from  this  group  has  been  applied  to  the  improvement  of 
32-bit  "higher"  level  languages  for  the  ILLIAC  IV.   Changes  to  the 
GLYHHR  language _,  to  facilitate  using  this  language  on  32-bit  data 
structure,  are  being  investigated.   Also,  the  requirements  for  the 
32-bit  data  handling  in  the  layout  of  new  languages  is  being  investigated. 
The  Kalman  Filter  Tracking  Program  [8]  which  previously  was  completely 
coded  in  assembly  language,  debugged,  and  executed  on  the  simulator,  has 
been  recoded  in  the  GLYPNIR  language.   The  program  was  used  to  evaluate 
what  32 -bit  capability  is  missing  in  GLYPNIR  and  to  obtain  an  idea  of 
the  efficiency  of  the  higher  level  language  on  this  type  of  problem. 

3' 5  Seismic  Signal  Processing 

Two  programs,  autocorrelation  and  cross  correlation,  both 
basic  requirements  for  a  signal  processing  system,  have  been  coded  in 
ASK  and  are  being  debugged  on  the  ILLIAC  IV  simulator. 

Both  programs  are  written  in  32-bit  and  6U-bit  floating  point 
mode,  using  the  same  algorithm  in  each  mode.   Because  the  seismic  data 
is  real  and  usually  contains  8-I3  significant  bits,  the  32-bit  mode 
allows  the  simultaneous  processing  of  two  data  streams;  whereas,  the 
64-bit  mode  provides  a  capability  for  those  users  whose  data  requires 
a  larger  word  size.   After  debugg;Lng,  the  programs  will  be  documented 
and  added  to  the  program  library  for  ILLIAC  IV. 
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3.6  Graphics 

Investigations  of  equipment  for  use  in  the  areas  of  inter- 
active graphics,  as  veil  as  microfilm  and  movie  recording  of  graphic 
and  alpha- numeric  records,  have  "been  in  progress. 

Contacts  vith  the  user  community  have  "been  made  in  order  to 
evaluate  the  Project's  requirements --present  and  future--for  this  type 
of  equipment.   Discussions  have  been  held  with  the  Project's  operating 
system  group  involved  in  data  communications  in  order  to  integrate  this 
particular  l/o  channel  into  the  system.   Vendors  have  been  approached 
and  we  have  learned  of  the  options  available  to  us  in  the  existing 
market. 

At  this  time,  we  expect  to  understand  our  requirements  and 
the  options  available  to  us  on  the  market  well  enough  to  request  a 
price  quotation  sometime  in  early  February,  with  delivery  of  equipment 
anticipated  in  the  Fall  of  1970. 

3.7  ILLIAC  IV  Education 

3.7.1  CS  i^91-D 

The  graduate  course  in  Computer  Science,  "Architecture, 
Application  and  Languages  for  a  Parallel  Computer,"  terminated  this 
quarter.   Based  on  the  feedback  from  the  students  we  will  concentrate 
more  heavily  on  programming  languages  next  semester,  particularly  in 
the  Assembly  Language  (ASK).   The  course  will  be  numbered  CS  491-E  for 
the  coming  semester;  the  course  outline  is  as  follows: 

I.   Hardware  6  classes 

II.   Operating  System  1  class 

III.   Programming  Languages     I7  classes 

ASK  6  classes 

GLYPNIR  5  classes 

FORTRAN  k  classes 

Storage  Schemes  2  classes 

rV.   Applications  5  classes 
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3'1'2     Training  Programs 

A  series  of  one-day  seminars  presenting  an  overview  of  ILLIAC 
will  be  offered  monthly,  stai-ting  in  late  February.  The  seminar  will 
he  primarily  for  orientation  of  new  project  personnel  but  will  also  act 
as  an  introduction  of  the  machine  to  University  personnel  and  other 
potential  ILLIAC  users.  Following  is  a  tentative  outline  of  the 
seminar : 

Algol  and  B5500  9:00  -  10:00  AM 

Hardware  10:00  -  noon 
Instruction  set  (general)      1:00  -  2:00  PM 
Available  software  3:00  -  4:00  IM 

Problem  types  and  solutions    it-: 00  -  5^00  HVI 

In  addition,  more  comprehensive  follow-up  courses  will  be 
offered  in  any  specific  area  (ASK,  GLYPNIR,  etc.)  if  enough  people  are 
interested. 

3«T«3  Documentation ' 

Currently  ACM  (Association  for  Computing  Machinery)  category 
codes  are  being  assigned  to  all  ILLIAC  IV  documents.   In  the  near  future, 
a  bibliography  of  all  ILLIAC  documents  (sorted  by  ACM  category  code) 
will  be  mailed  to  all  people  currently  on  our  mailing  lists.  Moreover, 
the  FOURUM  and  Research  Document  mailing  lists  will  be  combined  and  all 
ILLIAC  IV  documents  generated  within  and  without  the  ILLIAC  IV  project 
at  the  University  of  Illinois  will  be  assigned  ACM  codes  and  distributed 
through  FOURUM. 

3.7-^  ILLIAC  IV  Textbook 

Work  continues  on  the  text  which  shoiild  be  ready  toward  the 
end  of  the  third  quarter  of  1970. 
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ADMINISTRATION 


k.l     Administration  and  Services 

An  administrative  assistant  was  hired  in  mid-December  to 
establish  a  Project  Business  Office  (EBO);  thus,  future  reports  will 
contain  more  information  regarding  the  business  operation  of  the 
project. 

Bids  for  the  construction  of  the  Center  for  Advanced 
Computation  building  were  received  and  approved  by  the  University 
of  Illinois  Board  of  Trustees;  a  contractor  has  been  selected,  and 
construction  of  the  building  has  started.   The  expected  date  of 
completion  is  late  summer  or  early  fall  of  1970* 

One  of  the  initial  steps  taken  by  the  PBO  was  to  establish 
a  discrete  mailing  address,  as  follows: 

University  of  Illinois 

ILLIAC  IV  Project 

168  Engineering  Research  Laboratory 

Urbana,  Illinois  618OI 

At  the  present  time,  the  University  architect  is  working 
with  the  contractor  in  preparing  bids  for  the  electrical  and  mechanical 
systems  for  the  Center  for  Advanced  Computation.   Burroughs  is 
concurrently  gathering  similar  material  for  bidding  on  the  Environmental 
Control  System  of  the  Center. 

Studies  are  under  way  to  determine  the  need  of  an  automatic 
fire  extinguishing  system  on  the  computer  floor  and  the  machine  room. 
This  is  being  accomplished  through  consultation  with  the  University 
architect,  the  University  safety  officer,  and  Burroughs  Corporation. 
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